As the number of applications for computer systems increases, so does the power and ease of use of such applications. One feature which many systems and applications now include as a standard attribute is an undo feature. This undo feature will "undo" the last action performed by a user of the system. In effect, the application returns to the state of the application just before the user performed the last action.
More sophisticated applications allow users to undo several or all previous actions. For example, in a word processing program, a user could sequentially delete several lines of text, and then go back and undo the deletions, thereby re-inserting each line of deleted text. In a spreadsheet application, a user could change the formulas attached to various cells, but then decide to convert those cells back to their original formulas.
A user gains much more freedom and control over their work from the ability to easily undo previous actions. Users can experiment with different styles or appearances, and undo or redo any features they want. Further, it is human nature to make mistakes. An undo feature allows most mistakes to be easily amended, requiring much less time than manually taking the steps to revert an application to its previous state.
Most applications which allow users to undo several steps implement this feature by storing each user action on an action history stack. Although the action history stack may not be visible to a user, any implementation of a multiple undo feature will include some variation of a stack.
When the application starts up, the action history stack is empty. Each action performed by a user, for example entering some text, highlighting a block of text, or moving to a different part of a document, is stored on the action history stack. When a user wishes to undo one or more previous actions, the user activates the undo feature. Many applications allow the user to perform one or several undo actions at a time. Each undo action causes the last entry on the action history stack to be undone. The action is popped off the action history stack. When the user performs more actions, these new actions are pushed onto the action history stack.
One problem with undo actions is defining what is a single action. For example in a word processing application, each keystroke can be considered an action. However, undoing each keystroke would require a user to undo a vast number of actions to simply delete a couple of words. Therefore many word processors group various actions into a single action to be undone. For example, most word processors treat a group of keystrokes as one action which becomes the action of inserting text. This one action is pushed onto the action history stack. The user is stuck with the option of undoing the whole insertion of text, not just any portion of the keystrokes. Therefore, the user is confined with the application's description of what an undo action is.
This becomes even more problematical when a second application tries to drive the first application with the action history stack. For example, if the second application is sending actions to the first application to perform, the first application is storing actions on its action history stack. If the second application then needs to undo some actions, it must know exactly how the first application stores actions on the action history stack. Otherwise the second application will not be able to determine if it has undone the correct number or type of actions.
This situation is even worse if the second application is not the only source of actions to the first application. For example, suppose the first application is a word processing program and the second application is a voice recognition system. The voice recognition system interprets a human user's voice and inputs the spoken words to the word processing program. The user both dictates words to be typed into the word processing program, and commands for manipulating the displayed text in various ways. As the user dictates, she is also entering text or commands using the keyboard. Therefore actions are inserted onto the action history stack from two sources, the keyboard and the voice recognition system.
If the voice recognition system needs to undo several actions it performed, it cannot determine which actions were performed by the voice recognition system, and which were inserted by the keyboard. Further, the voice recognition system may want to group a set of actions as one action, in a different grouping than imposed by the word processing application. Since the voice recognition system has no control over what the word processor puts on the action history stack, the voice recognition system cannot undo actions in a reasonable way.
Accordingly, what is required is a system and method for allowing an application to monitor what is placed on an action history stack of another application, and thereby maintain some control as actions are pushed onto and popped off the action history stack.